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1 A METHOD FOR MAPPING PROCEDURAL C++ CODE 

2 TO JAVA OBJECT-ORIENTED CLASSES 

3 

4 Field of the Invention 

5 The invention relates to programming language interactions, and more 

6 specifically to legacy C++ GUI interactions with a Java environment. 

7 Background of the Invention 

8 In many software systems today, the existing or legacy graphical user 

9 interfaces ("GUIs") are coded in C++. Over the past few years, however, Java® has 

10 become the programming language of choice. In order to use Java for providing the 

1 1 functionality of a system, the C++ GUIs must be made useable with Java. One 

12 alternative is to rewrite all of the lines of C++ code in Java. Rewriting the C++ 

13 code may comprise rewriting many lines of code. In many situations this is 

14 impractical. Furthermore, in many situations, it is desirable to maintain the C++ 

15 GUIs, instead of replacing them, and to use them to interface Java objects and 

16 methods of the Java functional code. 

17 However, C++ is a procedural language while Java is an object-oriented 

18 language. Object-oriented programming is a method of programming that pairs 

19 programming tasks and data into re-usable chunks known as objects. Each object 

20 comprises attributes (i.e., data) that define and describe the object. Java classes are 

21 meta-definitions that define the structure of a Java object. Java classes when 

22 instantiated create instances of the Java classes and are then considered Java 

23 objects. Methods within Java objects are called to get or set attributes of the Java 

24 object and to change the state of the Java object. Associated with each method is 

25 code that is executed when the method is invoked. 

26 A task that is a sequence of steps in a C++ implementation likely involves 

27 the creation and/or manipulation of multiple objects in a Java implementation. 

28 Moreover, some tasks may require a remote method invocation ("RMI"). 

29 Unfortunately, coding Java object-creation or RMIs in C++ can be quite 

30 cumbersome. If C++ GUIs are maintained for accessing a Java implementation, the 

31 cumbersome coding of the tasks involving Java object-creation and RMIs will 

32 clutter the C++ GUIs. 

33 A solution to this problem would simplify the C++ GUI code by having Java 

34 object creation occur in Java. A solution would simplify access to first-class objects 
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1 of the Java implementation and provide a simple access to RMIs. A solution would 

2 allow simple C++ GUI callback code for creating and accessing Java objects. 

3 Summary of the Invention 

4 The present invention comprises a method and apparatus that maps 

5 procedural C++ code to Java object-oriented classes. A software component 

6 according to an embodiment of the invention is an Objectifier that is coded to call 

7 Java methods and make RMI calls as necessary to create and access Java objects in 

8 order to perform certain actions requested by C++ GUIs. The Objectifier is 

9 preferably a static Java class comprising a series of pass-through interfaces that may 

10 be accessed by executing simple C++ GUI callbacks. 

1 1 When a C++ GUI executes callback code to access a pass-through interface 

12 or entry-point, the Objectifier preferably executes Java method call(s) and/or 

^ 13 RMI(s), associated with the entry-point, in order to perform the requested action. 

»y 14 These entry-points thus map the procedural C++ code to the object-oriented Java 

J fj 15 code necessary to perform the action. The Objectifier preferably consolidates the 

J 16 Java object creations and RMIs that are used to conduct a process in Java. The C++ 

j s § 17 GUI callbacks may access the Objectifier directly through Java Native Interface 

I** 18 ("JNI") Application Programming Interface ("API") calls or through method calls to 

19 a C++ proxy of the Objectifier. The C++ proxy of the Objectifier preferably 

•h 20 includes a one-to-one mapping of Objectifier methods as well as the necessary 

jS 21 coding to make JNI API calls to the Objectifier. 

^22 A method according to an embodiment preferably comprises a user starting 

23 a C++ GUI in order to access a Java-based system, initializing a mapping layer 

24 (e the Objectifier), executing a C++ GUI callback, the mapping layer receiving a 

25 method call through an entry-point, the mapping layer executing an algorithm 

26 comprising a class instantiation and/or a RMI as determined by the entry-point, and 

27 if necessary, returning data to a C++ process space. 

28 These and other advantages are achieved by a method for mapping 

29 procedural code to object-oriented classes comprising, starting a graphical user 

30 interface ("GUI") in a procedural programming language process space, wherein a 

31 user enters a command through the GUI, initializing a mapping layer in an object- 

32 oriented programming language process space, wherein the mapping layer 

33 comprises entry-points that have corresponding algorithms that invoke object- 

34 oriented class instantiation methods and remote method invocations ("RMIs"), 



HP 10006819 



2 



1 executing a GUI callback in response to the command, wherein the GUI callback 

2 comprises procedural code and wherein executing a GUI callback in response to the 

3 command comprises invoking one of the entry-points, and the mapping layer 

4 executing an algorithm corresponding to the invoked entry-point. 

5 Likewise, these and other advantages are achieved by a computer system 

6 that enables the mapping of procedural code to object-oriented classes comprising a 

7 memory, a processor that runs an application, wherein the application generates a 

8 graphical user interface ("GUI") in a procedural programming language process 

9 space, wherein users enter commands through the GUI, and, a mapping layer in an 

10 object-oriented programming language process space, wherein the mapping layer 

1 1 comprises entry-points that have corresponding algorithms that invoke object- 

12 oriented class instantiation methods and remote method invocations ("RMIs"). 

13 These and other advantages are achieved by a computer readable medium 

14 containing instructions for mapping procedural code to object oriented classes, by 

15 starting a graphical user interface ("GUI") in a procedural programming language 

16 process space, wherein a user enters a command through the GUI, initializing a 

17 mapping layer in an object-oriented programming language process space, wherein 

18 the mapping layer comprises entry -points that have corresponding algorithms that 

19 invoke object-oriented class instantiation methods and remote method invocations 

20 ("RMIs"), executing a GUI callback in response to the command, wherein the GUI 

21 callback comprises procedural code and wherein executing a GUI callback in 

22 response to the command comprises invoking one of the entry-points, and the 

23 mapping layer executing an algorithm corresponding to the invoked entry-point. 

24 Brief Description of the Figures 

25 Figure 1 is a block diagram of a computer system on which an embodiment 

26 of a mapping layer may be run. 

27 Figures 2a and 2b are block diagrams conceptually illustrating an 

28 embodiment of the mapping layer and operation of the mapping layer. 

29 Figure 3 is a flowchart illustrating a method of mapping procedural code to 

30 object-oriented classes. 

31 Figure 4 is a static structure diagram of an embodiment of the mapping 

32 layer. 

33 Figure 5 is a sequence diagram illustrating an exemplary operation of the 

34 mapping layer. 
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Figure 6 is a sequence diagram illustrating an exemplary operation of the 
mapping layer. 

Detailed Description of the Invention 

The mapping layer may be used with computer systems that utilize C++ 
graphical user interfaces ("GUIs") to access Java objects across a Java Native 
Interface ("JNI"). Figure 1 illustrates a computer network system 10 with which the 
present invention may be used. The network system 10 comprises a ServiceControl 
Manager ("SCM") 12 running on a Central Management Server ("CMS") 14 and 
one or more nodes 16 managed by the SCM 12 on the CMS 14. Together the one or 
more nodes 16 managed by the SCM 12 make up a SCM cluster 17. A group of 
nodes 16 may be organized as a node group 18. 

The CMS 14 preferably is an HP-UX 1 1.x server running the SCM 12 
software. The CMS 14 includes a memory 143, a secondary storage device 141, a 
processor 142, an input device (not shown), a display device (not shown), and an 
output device (not shown). The memory 143, a computer readable medium, may 
include, RAM or similar types of memory, and it may store one or more 
applications for execution by processor 142, including the SCM 12 software. The 
secondary storage device 141, a computer readable medium, may include a hard 
disk drive, floppy disk drive, CD-ROM drive, or other types of non-volatile data 
storage. The processor 142 executes the SCM 12 software and other application(s), 
which are stored in memory 143 or secondary storage 141, or received from the 
Internet or other network 24, in order to provide the functions and perform the 
methods described in this specification, and the processing may be implemented in 
software, such as software modules, for execution by the CMS 14 and modes 16. 
The SCM 12 is programmed in Java® and operates in a Java® environment that is 
preferably accessed by using legacy C++ GUIs and the present invention. See 
ServiceControl Manager Technical Reference, HP part number: B8339-90019 , 
which is hereby incorporated by reference and which is accessible at 
http://www.software.hp.com/products/scmgr . for a more detailed description of the 
SCM 12. 

Generally, the SCM 12 supports managing a single SCM cluster 17 from a 
single CMS 14. All tasks performed on the SCM cluster 17 are initiated on the 
CMS 14 either directly or remotely, for example, by reaching the CMS 14 via a web 
connection 20. Therefore, a workstation 22 at which a user sits only needs a web 
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1 connection 20 over the network 24 to the CMS 14 in order to perform tasks on the 

2 SCM cluster 17. The workstation 22 preferably comprises a display, a memory, a 

3 processor, a secondary storage, an input device and an output device. In addition to 

4 the SCM 12 software and the HP-UX server described above, the CMS 14 

5 preferably also comprises a data repository 26 for the SCM cluster 17, a web server 

6 28 that allows web access to the SCM 12 and a depot 30 comprising products used 

7 in the configuring of nodes, and a I/UX server 32. 

8 The nodes 16 are preferably HP-UX servers or other servers and they may 

9 be referred to as "managed nodes 11 or simply as "nodes". The concept of a node 16 

10 is that it represents a single instance of HP-UX running on some hardware. The 

1 1 node 16 may comprise a memory, a secondary storage device, a processor, an input 

12 device, a display device, and an output device. 

13 Although the CMS 14 is depicted with various components, one skilled in 

14 the art will appreciated that this server can contain additional or different 

15 components. In addition, although aspects of an implementation consistent with the 

16 present invention are described as being stored in memory, one skilled in the art will 

17 appreciated that these aspects can also be stored on or read from other types of 

18 computer program products or computer-readable media, such as secondary storage 

19 devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the 

20 Internet or other network; or other forms of RAM or ROM. The computer-readable 

21 media may include instructions for controlling the CMS 14 (and/or the nodes 16) to 

22 perform a particular method, such as those described herein. 

23 Figure 2a conceptually illustrates an Objectifier 40 and operation of the 

24 Objectifier 40 according to the present invention. Figure 2a shows a C++ GUI 42 in 

25 a C++ process space 44, a Java Native Interface ("JNI") 46 and the Objectifier 40 

26 and a plurality of instantiated Java classes (as known as objects) 48 in a Java Virtual 

27 Machine ("JVM") 50, the Java process space. 

28 In the system 10, each user, node, node group, role, tool, authorization, user 

29 name, node name, and node group name is, for each instance, represented by a 

30 single Java object. A role defines the role {e.g., administrator, database manager, 

31 web manager, etc.) a user may have on a certain node(s) or node group(s), where 

32 each role has one or more tools associated with it that a user with the role may 

33 execute. A tool is an executable that performs some process. An authorization 
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invoked by at least one executed C++ GUI 42 callback. The entry -points 401 map 
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Figure 2a, when a user wants to perform some action (e.g., create a new user 




32 


object), a callback is executed and a method call (e.g., addUser()) is issued to the 




33 


Objectifier 40. The method call passes to the Objectifier 40 through an entry-point 




34 


401 corresponding to the invoked method. 



HP 10006819 



• ... # 

1 As shown above, performing a task (e.g., adding a user) in the JVM 50 may 

2 not simply be a sequence of procedural steps as it would be in a C++ 

3 implementation. Rather, one or more classes may need to be instantiated as objects 

4 48 (e.g,, a new user object needs to be created) in order to perform the task. For 

5 example, in order to create a new user object in the SCM 12 described above, the 

6 nodes, node groups, tools and roles that the new user is authorized to access may 

7 need to be determined. Consequently, certain utility classes (e.g., object managers 

8 49 that are used to access and manage the objects 48) may need to be accessed via a 

9 Remote Method Invocation ("RMI"). An RMI is used to access an object in a 

10 different JVM 50'. The object managers 49 may be housed in a domain manager 

1 1 (not shown) that is a module of the SCM 12 software that preferably runs on the 

12 CMS 14. 

13 Coding Java class instantiations, let alone a multiple-class instantiating 

14 process, is cumbersome in C++. The coding involves cluttering the C++ GUI 42 

15 callback code with the awkward procedural C++ implementation of an object- 

16 oriented process. Moreover, for many steps of the process, the C++ GUI 42 would 

17 have to instantiate a plurality of objects 48 in the JVM 50 through the JNI 46. 

18 Further, the C++ GUI 42 would have to accomplish RMIs through the JNI 46, a 

19 difficult and cumbersome requirement. 

20 Instead, the Objectifier 40 is coded with the necessary class instantiation(s) 

21 and RMIs 402 for performing the actions that may be requested by the C++ GUI 42 

22 callback code. Accordingly, associated with each entry-point 401 is the necessary 

23 class instantiation(s) and/or RMI(s) 402 for performing the action requested by the 

24 C++ GUI 42 method call corresponding to that entry-point 401, as depicted in 

25 Figure 2a. Therefore, the C++ GUI 42 callback code is not cluttered with awkward 

26 C++ creation of Java objects and awkward Java RMIs. Moreover, the Objectifier 

27 40 consolidates all of the class instantiations and RMIs in a single Java class so that 

28 the C++ GUI 42 method calls need be made to only a single Java class, the 

29 Objectifier 40. 

30 Consequently, a C++ GUI 42 method call to the Objectifier 40 triggers the 

31 execution of the object-oriented Java implementation of a requested action. The 

32 C++ GUI 42 method call need only invoke the Objectifier 40 method for the 

33 requested action in order to enter the Objectifier 40 through the correct entry-point 

34 401. For example, in order to store a newly-created user, the C++ GUI 42 may 
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1 execute a callback that invokes the Objectifier 40 method addUser(). This method 

2 call 'enters' the Objectifier 40 through an addUser() entry-point 401, triggering 

3 execution of the necessary RMI to store the new user object, as shown in Figure 2a. 

4 Since invocation of the Objectifier 40 method triggers the object-oriented process, 

5 the C++ GUI 42 callback code need not include Java object calls or RMIs 402. 

6 Figure 2b conceptually illustrates an alternative embodiment. In the 

7 embodiment shown in Figure 2b, the Objectifier 40 is proxied by a C++ proxy 

8 object 43. The C++ proxy object 43 preferably comprises methods that correspond 

9 to all of the methods of the Objectifier 40 and coding necessary to invoke the 

10 Objectifier 40 methods across the JNI 46. The coding necessary to invoke the 

1 1 Objectifier 40 methods across the JNI 46 includes JNI Application Programming 

12 Interface ("API") calls. 

13 In the embodiment shown in Figure 2b, the C++ GUI 42 callbacks execute 

14 the C++ proxy object 43 methods corresponding to the desired Objectifier 40 

15 methods, and the C++ proxy object 43 in turn executes the JNI API calls necessary 

16 to invoke the desired Objectifier 40 methods. Consequently, the JNI API calls are 

17 transparent to the C++ GUIs 42 and the C++ GUI 42 callback code is not cluttered 

18 with coding necessary for the JNI API calls. In the methods and sequence diagrams 

19 discussed below, the Objectifier 40 method invocations may be made by executed 

20 C++ GUI 42 callback code or by the C++ proxy object 43 shown in Figure 2b. 

21 Some of the objects and classes discussed herein are named with a prefix 

22 "mx". The mx prefix is indicative of the application utilizing the objects and 

23 classes (e.g., the SCM 12) and is merely exemplary. Indeed, the names of classes, 

24 objects and methods discussed herein are exemplary, are not intended to be limiting, 

25 and are merely used for ease of discussion. 

26 Figure 3 illustrates a process for mapping procedural C++ code to Java 

27 object-oriented classes 60 according to the present invention. The process 60 

28 comprises starting a GUI 61, initializing a mapping layer (e.g., the Objectifier 40) 

29 62, executing a GUI callback 64, invoking one of the entry-points 66 and the 

30 mapping layer executing an algorithm as determined by the entry-point 68. 

31 Starting a GUI 61 preferably comprises a C++ GUI 42 being started-up so 

32 that a user may enter commands through the C++ GUI 42. For example, the C++ 

33 GUI 42 may be run on a workstation so that the user may access the system 10 and 

34 the functionality of the SCM 12. When the C++ GUI 42 is started, it is preferably 
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1 displayed to the user on a display so that the user may interact with the C++ GUI 

2 42, making selections and entering commands with an input device such as a mouse 

3 or a keyboard. 

4 Initializing the mapping layer 62 preferably comprises instantiating the 

5 Objectifier class so that an instance of the Objectifier 40 object is present in the 

6 JVM 50 with which the C++ GUI 42 interacts. A C++ GUI 42 may initialize the 

7 mapping layer 62 early during the C++ GUI 42 startup code sequence. A C++ GUI 

8 42 startup code sequence is run when a user starts a C++ GUI 42 in order to access 

9 theSCM12. 

10 Executing a C++ GUI callback 64 preferably comprises the C++ GUI 42 

1 1 executing callback code, in response to a command entered by a user, to issue a 

12 method call to the JVM 50 in which the Objectifier 40 has been initialized. The 

13 method call preferably comprises a requested action and invokes a mapping layer 

14 entry-point 641 (e.g., invokes an Objectifier 40 method). For example, in the 

15 system 10 described above, the requested action may comprise retrieving, adding, 

16 deleting or storing a user, node, node group, tool, role, authorization, determining 

17 validity of node, node group, tool or role name, determining if user, node name, etc 

18 is defined, etc. Accordingly, in the system 10, the executed callback may make a 

19 method call invoking, for example, Objectifier 40 methods such as addUser, 

20 deleteNode, modifyNodeGroup, runTool, getAuthorization, isValidToolName, etc. 

21 The mapping layer receiving a method call through an entry-point 66 

22 preferably comprises the Objectifier 40 receiving the C++ GUI 42 method call after 

23 the method call has passed through the JNI 46. The Objectifier 40 method invoked 

24 by the method call is the entry-point of the C++ GUI 42 method call. The 

25 Objectifier 40 methods preferably comprise code comprising class instantiations 

26 and/or a RMI(s). Some Objectifier 40 methods may comprise code invoking local 

27 Java methods (i.e., in Java classes in the same JVM 50 as the Objectifier 40). 

28 Accordingly, the mapping layer executing an algorithm (comprising a class 

29 instantiation and/or a RMI) as determined by the entry-point 68 preferably 

30 comprises the Objectifier 40 executing the invoked method, which in turn executes 

31 the code associated with the executed method. 

32 Consequently, as shown in Figure 3, the mapping layer executing an 

33 algorithm associated with the entry-point 68 may comprise instantiating a class (i.e., 

34 Java object 48 creation) 682, invoking a local Java method 684 and/or making an 
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1 RMI 686. If the C++ GUI 42 requires data to be returned (e.g., the executed 

2 callback requires a list of nodes to be displayed to the user for selection), executing 

3 an algorithm associated with the entry-point 68 further comprises returning data to 

4 the C++ process space 688. 

5 Returning data to the C++ process space 688 may comprise returning a 

6 pointer to, or the actual value of, data such as an Integer, Long, String, Boolean, etc. 

7 that provides a value requested by the C++ GUI 42 method call. For example, if the 

8 C++ GUI 42 method call asks for a list of nodes, Node Name Strings may be 

9 returned. Returning data to the C++ process space 70, however, may also comprise 

10 returning a Java object 48 to the C++ process space 44. Returning a Java object 48 

11 to the C++ process space 44 may comprise passing the Java object 48 name and 

12 instance data (i.e., data that describes the Java object 48) so that the Java object 48 

13 can be proxied in the C++ process space 44. Exemplary execution of steps 682-688 

14 is illustrated in Figures 5 and 6, described below. As shown in Figure 3, step 682, 

15 step 684, step 686 and step 688 may be repeated if the method's algorithm requires 

16 a plurality of class instantiations, Java method calls and/or RMIs. 

17 As noted above, the Objectifier 40 is coded with the entry-points 401 (i.e., 

18 methods) and corresponding methods as necessary to consolidate the class 

19 instantiations, Java method calls, and RMIs for performing the actions that may be 

20 requested by executed C++ GUI 42 callbacks. Consequently, the Objectifier 40 

21 may be customized according to the system in which it is utilized. In a system 

22 different from the computer system 10 shown in Figure 1, different methods may be 

23 required in the Objectifier 40. The methods in the Objectifier 40 may be modified 

24 or removed, and new methods may be added, as required. 

25 Figure 4 illustrates a static structure diagram 80 of an exemplary 

26 embodiment of the Objectifier 40 for use in the computer system 10 shown in 

27 Figure 1. The Objectifier 40 is preferably a component of the SCM 12 software that 

28 maps procedural C++ code to object-oriented Java via entry-points accessible by 

29 C++ method invocations. As seen in Figure 4, the static structure diagram 80 

30 illustrates certain Objectifier data 82 and pass-through interfaces or entry-points 84 

31 (corresponding to the entry-points 401 in Figures 2a and 2b). 

32 The Objectifier data 82 may include, for example, various data that the 

33 Objectifier 40 and external sources (e.g., CLIs and GUIs) may utilize when the 

34 Objectifier 40 is running. For example, the Objectifier data 82 may include a 
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1 variable {e.g., ourCurrentlyExecutingUserName) in which the Objectifier 40 saves 

2 the current OS user login name so that the Objectifier 40 can service requests from, 

3 for example, the GUI that require knowledge of the currently logged in OS user. 

4 The Objectifier data 82 may include a variable {e.g., ourObjectifierlnitializedFlag) 

5 that contains data {e.g., true or false) that indicates whether the Objectifier 40 is 

6 initialized. This variable is preferably set to false during class loading and to true 

7 when, for example, the GUI calls the initObjectifier method. 

8 Moreover, the Objectifier data 82 may include an Objectifier 40 tracer name 

9 {e.g., TRACER_NAME) for which an external CLI can query a base tracer object to 

10 modify the Objectifier's tracing level {i.e., the level of monitoring of the Objectifier 

11 40 for exceptions, etc.). Additionally, the Objectifier data 82 may include a variable 

12 {e .g., DEBUG) that identifies an object used by the Objectifier 40 to log debug 

13 output to the Objectifier 40 trace file. The Objectifier 40 trace file name may be 

14 contained in another variable {e.g., OBJECTIFIER_DEBUG_FTLENAME) that 

15 may be included in the Objectifier data 82. 

16 Further, the Objectifier data 82 may include a variable {e.g., 

17 MxSessionManagerlfc ourSMIfc) that identifies a Session Manager interface object. 

18 When the Objectifer 40 needs to access a SCM 12 domain manager, the Objectifier 

19 40 preferably queries the Session Manager interface object for a particular interface 

20 for the SCM 12 domain manager. Likewise, the Objectifier data 82 may include a 

21 cached version {e.g., ourMxProps) of a SCM 12 properties file from which to obtain 

22 IP port numbers, service names, debug flag values, etc. 

23 The entry-points 84 comprise methods that may be invoked by an executed 

24 C++ GUI 42 callback or by the C++ proxy object 43. The entry-points 84 are 

25 shown in the following format: + method name (parameter, if any): returned data. 

26 For example, + addUser(MxUser userObject):void is a method with the method 

27 name addUser, the parameter MxUser userObject, which requires that an addUser 

28 invocation include the name of the MxUser object 48 that is to be added, and a 

29 returned data "void" {i.e., no data is returned to the C++ process space 44). 

30 Likewise, + getTool():MxTool is a method named getTool with no parameters, and 

31 a MxTool Java object 48 as the returned data {i.e., the MxTool Java object 48 

32 instance data will be passed to the C++ process space 44 so that the MxTool Java 

33 object 48 may be proxied in the C++ process space 44). 
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1 For certain accessor methods (e.g., getTool()), if a parameter value is absent, 

2 the invoked accessor method will return an empty object (e.g., an empty tool 

3 object). Such a method invocation is made, for example, in order to create a new 

4 tool, user, node, node group or role object. If a parameter value is present (e.g., 

5 getTool(String toolName)), the invoked accessor method will return a specific 

6 object indicated by the parameter value (e.g., a specific tool indicated by toolName). 

7 Accordingly, a C++ GUI 42 in the computer system 10 may issue method 

8 calls (e.g., by executing a callback) corresponding to any of the entry-points 84 

9 shown in the static structure diagram 80. In order to successfully enter an entry- 

10 point 84 of the embodiment of the Objectifier 40 shown, the C++ GUI 42 method 

1 1 call includes one of the method names and associated parameters (if any) shown. 

12 When the embodiment of the Objectifier 40 receives one of the method names and 

13 associated parameters (if any) shown in Figure 4, the Objectifier 40 executes an 

14 algorithm (i.e., code) associated with the method identified by the received method 

15 name. 

16 Figure 5 depicts a sequence diagram 100 illustrating an exemplary process 

17 utilizing the embodiment of the Objectifier 40 illustrated by the static structure 

18 diagram in Figure 4. The process shown creates a new user of the SCM 12. As 

19 seen in Figure 5, the process for creating a new user of the SCM 12 includes a 

20 plurality of C++ GUI 42 method calls to the Objectifier 40 and a plurality of 

21 executed method algorithms corresponding to the entry-points 84 invoked by the 

22 C++ GUI 42 method calls. 

23 The sequence diagram 100 includes boxes representing the C++ GUI 42 (or, 

24 alternatively the C++ proxy object 43), the Objectifier 40, and a series of 

25 implementation and utility Java classes 102. Time-lines 1 12 descend from each of 

26 these boxes, representing the continuous running of the C++ GUI 42, Objectifier 40 

27 and the Java classes 102. The Java classes 102 include an implementation class 

28 MxOS (a Java object instantiated in the JVM 50 for accessing operating system 

29 data), remote utility classes NodeManager, UserManager, RoleManager and 

30 SecurityManager (object managers 49 housed in a domain manager and present in 

31 remote JVMs 50' and accessible with RMI), and MxUser and MxAuthorization 

32 implementation classes (first-class Java objects 48 instantiated in the JVM 50). 

33 The sequence diagram 100 also includes method call-lines 104 representing 

34 Objectifier 40 methods invoked (with necessary JNI API calls to access the 
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1 Objectifier 40 via the JNI 46 boundary) by executed C++ GUI 42 callbacks (or, 

2 alternatively, by the C++ proxy object 43 in response invocations by executed C++ 

3 GUI 42 callbacks) and utility and implementation class methods and RMIs invoked 

4 by the Objectifier 40. The relative vertical position of the method call lines 104 

5 indicates the sequential order in which the Objectifier 40 or utility and 

6 implementation class 102 methods are invoked; the sequence starts at the top and 

7 moves to the bottom of the sequence diagram 100. Note that "names" (e.g., user 

8 names, node names, etc.) are generally id numbers (id#s) mapped to name strings; 

9 the C++ GUI 42 preferably displays the name strings to the user while the classes 

10 use the id#s to identify the Java objects 48 associated with the "names". 

11 As seen in Figure 5, the first method call-line 104 represents the invocation 

12 of an Objectifier method initObjectifier(). The initObjectifier() method initializes 

13 an instance of the Objectifier 40 in the JVM 50 with which the C++ GUI 42 

14 interacts. Preferably, the initObjectifierf) method is invoked during the C++ GUI 

15 42 startup code sequence. Indeed, the first four method call-lines 104 issuing from 

16 box representing the C++ GUI 42, including the initObjectifierf ) method call-line 

17 104, represent Objectifer 40 methods preferably invoked during the C++ GUI 42 

18 startup code sequence. 

19 When initialized, the Objectifier 40 retrieves, from the operating system 

20 ("OS"), the login name (i.e., the userid#) of the user currently using the C++ GUI 

21 42 to interact with the SCM 12. This retrieval is represented by a 

22 getCurrentLoginName() method call-line 104. The implementation class MxOS 

23 102 is an implementation class instantiated in the JVM 50 to facilitate accessing 

24 data from the OS. As such, the Objectifier 40 invokes the MxOS method 

25 getCurrentLoginNameO to retrieve the name of the current user. 

26 A getCurrentUserQ method call-line 104 illustrates the C++ GUI 42 

27 invocation of an Objectifier 40 method to retrieve the userid # of the current user. 

28 A isOSUserf) method call-line 104 illustrates the C++ GUI 42 invocation of an 

29 Objectifier 40 method that determines whether the current user is a registered OS 

30 user. If the current user is not a registered OS user, the getCurrentLoginNameO 

31 invoked above will not return a name for the current user and the isOSUserf) 

32 method will return a boolean false. If the isOSUserf) returns a false, the C++ GUI 

33 42 will display an error message to the current user and will not continue with the 

34 process shown in Figure 5. 
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1 If the isOSUser() returns a true, the process continues. A getUser() method 

2 call-line 104 illustrates the invocation of an Objectifier method that returns instance 

3 data of a Java user object 48 (e.g., a MxUser object 48) that represents a SCM 12 

4 user. Here, the getUseri) method is invoked with the name of the current user. 

5 Consequently, if the current user is a SCM 12 user, the getUseri) method will return 

6 the instance data of the MxUser object 48 that represents the current user to the C++ 

7 process space 44. 

8 As shown by the read() method call-line 104, the code associated with the 

9 getUserf) method causes the Objectifier 40 to invoke a UserManager utility 

10 classl02 read() method via a RMI, since the UserManager utility class 102 is in a 

1 1 remote JVM. If the current user is a SCM 12 user, a populated MxUser object 48 

12 will already exist for the current user and the UserManager is accessed to retrieve 

13 this MxUser object 48. Accordingly, the read() method will return the instance data 

14 of the current user's MxUser object 48. If the current user is not a SCM 12 user, a 

15 MxUser object 48 will not exist for the current user and the read() method (as well 

16 as the getUser() method above) will generate an exception caught by the Objectifier 

17 40. If no instance data is returned or if the attributes of the current user's MxUser 

18 object 48 show that the current user is not authorized to add new users (e.g., the 

19 current user does not have the SCM privilege (SCM privileges control access to the 

20 structure of the SCM itself) that allows adding of SCM 12 users), the process shown 

21 in Figure 5 will not continue and an appropriate error message will be displayed by 

22 the C++ GUI 42. 

23 The four methods described above are preferably invoked by the C++ GUI 

24 42 startup process code. In other words, when a user starts a C++ GUI 42 in order 

25 to access and perform a task (e.g., add a SCM 12 user) in the SCM 12, the C++ GUI 

26 42 initializes the Objectifier 40, gets the current user's userid#, determines if the 

27 current user is a registered OS user, and gets the current user's MxUser Java object 

28 40 to determine whether the current user is an SCM 12 user and whether the current 

29 user has the SCM privilege to perform the task (e.g., add a SCM 12 user) on the 

30 SCM 12. If the current user is so privileged, the C++ GUI 42 will continue to 

31 execute callbacks in order to facilitate performance of the task. 

32 Accordingly, the C++ GUI 42 will prompt the current user to enter the name 

33 of the new SCM 12 user that the current user wants to add. In response to the 

34 entered name, the C++ GUI 42 preferably executes a callback to determine whether 
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1 the entered name is an existing SCM 12 user. The executed C++ GUI 42 callback 

2 in turn invokes an Objectifier 40 method to determine whether the entered name is a 

3 defined SCM user name, as shown by the isDefinedUser() method call-line 104 in 

4 Figure 5. As with all the C++ GUI 42 method invocations shown in Figure 5 and 

5 discussed herein, alternatively, the executed callback may invoke a C++ proxy 

6 object 43 method that would in turn invoke the Objectifier 40 method shown (i.e., 

7 isDefinedUserO) and the necessary JNI API call. 

8 Since the User Manager utility class 102 (e.g., MxUserManager) maintains 

9 the MxUser Java objects 48 for existing SCM 12 users, the code associated with the 

10 isDefinedUserO method invokes a User Manager method (shown by the 

1 1 isNameDefinedO method call-line 104) to determine if the entered name is 

12 associated with an existing MxUser object 48. The isNameDefinedO method 

13 preferably returns a boolean true if the entered name is associated with an existing 

14 MxUser object 48 and a boolean false otherwise. The isDefinedUserO method 

15 returns the result to the C++ process space 44. 

16 If the entered name is not associated with an existing MxUser object 48 (i.e., 

17 the name entered in the C++ GUI 42 by the current user is not an existing SCM 12 

18 user's name), the C++ GUI 42 callback invokes an Objectifier 40 method (shown by 

19 the getUser() method call-line 104) to get an empty MxUser object 48 with which to 

20 construct a new SCM 12 user. The code associated with the getUser() method 

21 invokes a constructor method MxUser() on the MxUser class 102. The MxUser() 

22 method instantiates an instance of the MxUser class, creating an empty MxUser 

23 object 48, and returns the MxUser object 48 instance data to the Objectifier 40. The 

24 getUseri) method returns this instance data to the C++ process space 44 so that it 

25 may be proxied. 

26 Referring to Figure 5, the getUserAttributes() method call-line 104 

27 illustrates the invocation of an Objectifier 40 method to retrieve the new SCM 12 

28 user's attributes. In order to be added as a SCM 12 user, the new SCM 12 user must 

29 be a registered OS user. As such, the getUserAttributes() method invokes a MxOS 

30 class 102 method to retrieve OS user data associated with the entered name (passed 

31 by the C++ GUI 42). The OS user data may include, for example, phone numbers, 

32 email addresses and userid#s. If the entered name is a registered OS user, the 

33 getOSUserDataO method returns OS user data associated with the entered name. If 
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the entered name is not a registered OS user, no OS user data will be returned and 
the entered name will not be added as a new SCM 12 user. 

A getNodeNames() method call-line 104 illustrates invocation of an 
Objectifier 40 method to retrieve names for nodes that the current user has selected 
for the new SCM 12 user. Preferably, the C++ GUI 42 presents a list of Nodes for 
which the current user may select to give the new SCM user 12 authorizations. The 
selected node names are passed to the Objectifier 40 with the getNodeNames() 
invocation. As shown by the list() method call-line 104, the code associated with 
the getNodeNames() method invokes a Node Manager method, via a RMI, to list 
and return the names for the selected nodes. The Node Manager class 102 (e.g., 
MxNodeManager) is a utility class that manages the objects that represent the nodes 
16 of the SCM 12. 

A getRoleN antes AndIDs() method call-line 104 illustrates invocation of an 
Objectifier 40 method to retrieve names and id#s for roles that may be selected for 
the new SCM 12 user. The code associated with the getRoleNamesAndIDs() 
method invokes a Role Manager method (shown by the second list() method in 
[ 5 j 17 Figure 5), via a RMI, to list and return the names and id#s for the roles. The Role 

Lu 1 Q Manager class 102 (e.g., MxRoleManager) is a utility class that manages the objects 

p 19 that represent the roles of the SCM 12. 

For each SCM 12 user, there is a user object (e.g., the MxUser object 48) 
and zero or more Java authorization object(s) 48 (e.g., Mx Authorization Java 
objects 48) that define the nodes and roles that the SCM 12 user is authorized to 
access. Accordingly, as shown in Figure 5, a getAuthorization method call-line 
illustrates the invocation of an Objectifier 40 method to create a new authorization 
(e.g., a role and a node) for the new SCM 12 user. Preferably, the getAuthorization 
method is invoked for each authorization created for the new SCM 12 user (i.e., 
each role and node, etc.). An MxAuthorization method call-line 104 illustrates that 
the code associated with the getAuthorization method invokes a MxAuthorization 
constructor method on the MxAuthorization class, instantiating an instance of an 
empty MxAuthorization Java object 48. The getAuthorization method returns the 
instance data of the MxAuthorization Java object 48 to the C++ process space 44 so 
that the MxAuthorization Java object 48 may be proxied. 

An addUser() method call-line 104 illustrates the invocation of an 
Objectifier 40 method to add the new SCM 12 user to the User Manager. Instance 
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data for the MxUser object 48, and user data, such as the new SCM 12 user's OS 
user data retrieved above and the userid of the current user, and the identifiers of the 
authorizations created above, are passed with the addUser() method invocation to 
fill-in the new, empty MxUser object 48, which was created as described above. 
Preferably, the C++ GUI 42 fills in an empty MxUser object 48 (e.g., by invoking 
mutator methods via the C++ proxy), with this instance data, user data and the 
identifiers, and passes a reference to the Java object to the Objectifier 40 with the 
addUserf) invocation. Consequently, the Objectifier 40 invokes the User Manager 
add() method, via a RMI, to add the filled-in MxUser object 48 to the User 
Manager. 

As shown in Figure 5, the saveAuthorizationsQ method call-line 104 
illustrate the invocation of an Objectifier 40 method, and in turn, a Security 
Manager method, via a RMI, to save the filled-in MxAuthorization Java objects 48 
created above for each authorization of the new SCM 12 user. The instance data of 
the filled-in MxAuthorization Java objects 48 and the data identifying the 
authorizations selected are passed with the save Author izations() method 
invocations. The Security Manager (e.g., MxSecurityManager) maintains the 
MxAuthorization Java objects 48. 

Other processes utilizing the embodiment of the Objectifier 40 shown in 
Figure 4 operate similarly to the process shown in Figure 5. I.e., the C++ GUI 42 
callbacks are coded with procedural code for a step-by-step process to add, delete, 
store, etc. a user, node, role, etc. by invoking Objectifier 40 methods (directly or 
through the C++ proxy object 43) that execute the Java object creation and RMIs 
necessary to complete the process in object-oriented Java. 

According to this same principal of operation, Figure 6 depicts another 
sequence diagram 200 illustrating an exemplary process utilizing the embodiment of 
the Objectifier 40 shown in Figure 4. The process shown by Figure 6 is for adding a 
new node 16 to the SCM 12. The sequence diagram 200 includes boxes 
representing the C++ GUI 42 (or, alternatively the C++ proxy object 43), the 
Objectifier 40, and a series of implementation and utility Java classes 102. Some of 
the method invocations, such as most of the methods discussed above that are 
invoked during the C++ GUI 42 startup code process, are omitted from the sequence 
diagram 200 of Figure 6. Repetitive method invocations, such as initObjectifier() 
and getCurrentUser() y are not discussed again. 
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1 The sequence diagram 200 in Figure 6 includes method invocations that may 

2 not be invoked every time a new node 16 is added. For example, the a new node 16 

3 may be added by invoking getNode() y isValidNodeName() 9 isDefinedNodeNamef) 

4 and addNodef) Objectifier 40 methods described below. Likewise, if a user creating 

5 a new node 16 wishes to add the node to a node group 16, getNodeGroupNamesf) 

6 and ModifyNodeGroupQ Objectifier 40 methods described below may also be 

7 invoked. As with Figure 5, "names" (e.g., user names, node names, etc.) are 

8 generally id numbers (id#s) mapped to name strings; the C++ GUI 42 preferably 

9 displays the name strings to the user while the classes use the id#s to identify the 

10 Java objects 48 associated with the "names". 

11 A getNode() method call-line 104 illustrates the invocation of an Objectifier 

12 40 method that returns an instance of a Java node object 48 (e.g., a MxNode Java 
m 13 object 48) that represents a node 16. The code associated with the getNodef) 

\§ 14 method invokes a constructor method MxNode() of the MxNode class 102. The 

IB 

m 15 MxNode() method instantiates an instance of the MxNode class, creating an empty 

8 Hi 16 MxNode object 48, and returns the MxNode object 48 instance data to the 

jgi 17 Objectifier 40. The getNodef) method returns this object to the C++ process space 

W 18 44 so that it may be proxied. 

rn 19 An isValidNodeName() method call-line 104 illustrates the invocation of an 

jjj: 20 Objectifier 40 method to determine if a name, entered by the current user of the C++ 

jffs 21 GUI 42, is a valid name for a node 16. Preferably, the SCM 12 has certain syntax 

H 22 rules for valid node 16 names that need to be satisfied. A node 16 name is 

I* 

23 preferably represented by a Java node name object 48 (e.g., a MxNodeName Java 

24 object 48). As seen by a MxNodeNameQ method call-line, the Objectifier 40 

25 attempts to determine if the entered name is a valid node 16 name by invoking a 

26 MxNodeName implementation class 102 constructor method to create a 

27 MxNodeName object 48 with the entered name. The Objectifier 40 passes the 

28 entered name with the MxNodeName() invocation and if the entered name is a valid 

29 node 16 name, the MxNodeName implementation class 102 creates a 

30 MxNodeName object 48 with the entered name. If the MxNodeName object 48 is 

31 created, a Boolean true is returned to the C++ process space 44. Otherwise, the 

32 C++ GUI 42 preferably displays an error message to the current user and the 

33 process ends until a valid node 16 name is entered. 
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An isDefinedNodeNamef) method call-line 104 illustrates the invocation of 
an Objectifier 40 method that determines whether a node 16 already exists. This 
method may be invoked after the entered name has been determined to be valid, as 
described above. A name is passed to the Objectifier 40 with the 
isDefinedNodeNamef) method invocation. Since the Node Manager utility class 
102 maintains existing MxNode objects 48, the Objectifier 40 invokes a Node 
Manager method, via a RMI, to determine if a MxNode object 48 with the same 
name already exists. This Node Manager method invocation is shown by the 
isDefined() method call-line 104. The isDefinedf) method returns a boolean true or 
false, which is in turn, passed to the C++ process space 44 by the 
isDefinedNodeNamef) Objectifier 40 method. 

A getNodeNamesf) method call-line 104, seen in Figure 6, illustrates the 
invocation of an Objectifier 40 method to return certain node 16 names {e.g., a list 
of all node 16 names). Associated with the getNodeNamesf) method is code that 
invokes a Node Manager method, via a RMI, that retrieves a list of specified node 
16 names from the Node Manager utility class 102. The C++ GUI 42 may execute 
callback code to get certain node 16 names if, for example, the current user 
indicated that he/she wants to create a new node group 18 with the new node 16 and 
existing nodes 16. Instance data describing the MxNodeName object(s) 48 for the 
listed node(s) 16 is preferably returned to the C++ process space 44. 

A getNodeGroupNamesf) method call-line 104 illustrates the invocation of a 
similar Objectifier 40 method to return certain node group 18 names {e.g., a list of 
all node group 18 names). The getNodeGroupNamesf) method functions similarly 
to the getNodeNamesf) method, only a Node Group Manager utility class 102 {e.g., 
a MxNodeGroupManager) method is invoked, via a RMI, to retrieve a list of 
specified node group 18 names. The C++ GUI 42 may execute callback code to get 
certain node group 18 names if, for example, the current user indicated that he/she 
wants to add the new node 16 to an existing node group 18. Instance data 
describing the MxNodeGroupName object(s) 48 for the listed nodes group(s) 18 is 
preferably returned to the C++ process space 44. 

A getUserNamesf) method call-line 104, shown in Figure 6, illustrates the 
invocation of a Objectifier 40 method to return certain user names {e.g., a list of all 
SCM 12 user names). The getUserNamesf) method functions similarly to the 
getNodeNamesf) method and getNodeGroupNamesf) method described above, only 
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1 a User Manager utility class 102 method is invoked, via a RMI, to retrieve a list of 

2 specified SCM 12 user names. The C++ GUI 42 may execute callback code to get 

3 certain SCM 12 user names if, for example, the current user indicated that he/she 

4 wants to enable certain users to access the new node 16. Instance data describing 

5 the MxUserName object(s) 48 for the listed SCM 12 users is preferably returned to 

6 the C++ process space 44. 

7 A getRoleN antes AndIDs() method call-line 104 illustrates invocation of an 

8 Objectifier 40 method to retrieve names for roles that may be selected as authorized 

9 to be utilized on the new node 16. As discussed above with reference to Figure 5, 

10 the code associated with the getRoleN antes AndlDs() method invokes a Role 

1 1 Manager method, via a RMI, to list and return the names for the roles. The read() 

12 method call-line illustrates that the Objectifier 40 loops to get the MxRole objects 
i=f ,_ 13 from which it extracts the id#s for the SCM 12 roles. The C++ GUI 42 may execute 
iQ 14 callback code to get certain SCM 12 role names and ids if, for example, the current 

15 user indicated that he/she wants to enable certain roles to be utilized on the new 

16 node 16. Preferably, the C++ GUI 42 uses displays the role names to the user and 
j*l 17 uses the role ids (and userids, node ids and node group ids) to build the 

W 18 authorization objects. 

i 

P 19 An addNodef) method call-line 104 illustrates invocation of an Objectifier 

20 40 method to store the new node 16 with the Node Manager utility class 102. 

I if I 21 Instance data for the MxNode object 48, and node data, such as instance data of the 

! Itr= 22 MxNodeName object 48 created as described above and the creating user's userid in 

23 a createdBy field of the MxNode object 48, are passed to the Objectifier 40 with the 

24 addNodef) method invocation which was created as described above. 

25 Consequently, the Objectifier 40 invokes the Node Manager add() method, via a 

26 RMI, to add the filled-in MxNode object 48 to the Node Manager. Subsequently, 

27 the new node 16 may be accessed by accessing the new filled-in MxNode object 48 

28 from the Node Manager. 

29 A getNodeGroupf) method call-line 104 illustrates invocation of an 

30 Objectifier 40 method to create a new node group 16. As seen in Figure 6, 

31 associated with this method is a constructor method MxNodeGroup that the 

32 Objectifier 40 invokes in the MxNodeGroup implementation class 102. This 

33 constructor method instantiates an empty instance of an MxNodeGroup object 48 

34 and passes the empty MxNodeGroup object 48 to the Objectifier 40. The 
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As illustrated by the exemplary sequence diagrams 100, 200 in Figures 5 
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and 6, the Objectifier 40 is a component of the SCM 12 software that acts as a layer 
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between the C++ process space 44 and the method invocations and RMIs necessary 
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in the object-oriented JVM 50. As shown, the Objectifier 40 consolidates the Java 
object 48 creations and RMIs that are used to conduct a process in Java. The 
Objectifier 40 maps the procedural C++ code of the C++ GUI 42 callbacks to the 
Java object-oriented utility and implementation classes. 

While the invention has been described with reference to the exemplary 
embodiments thereof, those skilled in the art will be able to make various 
modifications to the described embodiments of the invention without departing from 
the true spirit and scope of the invention. The terms and descriptions used herein 
are set forth by way of illustration only and are not meant as limitations. Those 
skilled in the art will recognize that these and other variations are possible within 
the spirit and scope of the invention as defined in the following claims and their 
equivalents. 
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